We do not need pod to pod communication, so setting the pod into hostNetwork mode makes it work even when CNI is not working.

I have multiple question about it:

• as an Operator for CRDs, this agent needs to connection to the Kubernetes API, what availability guarantees you have with hostNetwork?
• hostNetwork strips an important part of the container isolation, making the whole host networking available to limited-privileged application and also exposing this application with elevated rights to systemd and libvirt components to the network. In case we start using network policies, host networking will circumvent any security.
• What's the benefit - pod networking is a precursor for any kubernetes workload, including openstack components. I don't see any benefit this agent has from running independently.

That matches the behaviour of the agents.

Please elaborate

as an Operator for CRDs, this agent needs to connection to the Kubernetes API, what availability guarantees you have with hostNetwork?

The kubernetes api server for the cluster do not run inside the shoot cluster, but inside the seed cluster. The API is usable without CNI, and as observed in with our blue nodes where the CNI was failing, it improves the availability, as it still works in that case.

hostNetwork strips an important part of the container isolation...

I am missing the question here. What is the attack scenario you have in mind?

What's the benefit - pod networking is a precursor for any kubernetes workload, including openstack components.

That is not correct. The agents are running in hostNetwork mode. Pod networking is the requirement of any kubernetes workload, requiring pod-to-pod communication, such as ingress, services, etc...
CNI itself is a kubernetes workload running in hostNetwork mode for obvious reasons.

The benefit is having one less component that might fail involved as demonstrated in our blue nodes, where everything except this agent was working, despite the CNI being broken.

The kubernetes api server for the cluster do not run inside the shoot cluster, but inside the seed cluster. The API is usable without CNI, and as observed in with our blue nodes where the CNI was failing, it improves the availability, as it still works in that case.

As far as I see DNS resolving by coredns is still a pod inside the shoot cluster.

hostNetwork strips an important part of the container isolation...

I am missing the question here. What is the attack scenario you have in mind?

lmgtfy:

• https://securitylabs.datadoghq.com/cloud-security-atlas/vulnerabilities/use-of-host-network-containers/
• https://cheatsheetseries.owasp.org/cheatsheets/Kubernetes_Security_Cheat_Sheet.html
• https://kubernetes.io/docs/concepts/security/pod-security-standards/

That is not correct. The agents are running in hostNetwork mode. Pod networking is the requirement of any kubernetes workload, requiring pod-to-pod communication, such as ingress, services, etc... CNI itself is a kubernetes workload running in hostNetwork mode for obvious reasons.

The benefit is having one less component that might fail involved as demonstrated in our blue nodes, where everything except this agent was working, despite the CNI being broken.

The agent's are running in hostNetwork because you didn't cared to harden them, it's not clear if all containers need to run in hostNetwork. So the argument is invalid.
It's true that currently the kvm-node-agent doesn't need direct access to another external resource except kube-api - but it doesn't mean it has to stay.

If you can elaborate the what benefits you see in not relying on CNI and how they outweighs the security issues.

This PR is stale because it has been open for 45 days with no activity.

This PR was closed because it has been inactive for 14 days since being marked as stale.